Processors may operate in several processor operating modes depending upon the immediate requirements of system operation. Generally processors may have a supervisor mode, a user mode, and sometimes other special-purpose modes. Supervisor mode may support the execution of the operating system, and may enable the execution of most instructions, including privileged instructions. Access may be given in supervisor mode to a different address space and peripheral devices. User mode may be restricted to non-privileged instructions when compared with supervisor mode, so that user code may not disrupt system functionality.
It is often the case that commercially released software is not a perfect fit on a particular original equipment manufacturer's (OEM) hardware suite. Due to specification misunderstandings or implementation errors, there may be situations where the software attempts to access hardware in a manner not anticipated or supported by the hardware. A simple example could be where a software program expects to place a value in a register at address x whereas the actual register in the hardware is at different address y. This could cause the system to malfunction or behave unpredictably.
In order to deal with such situations, processors may be designed to support an operating mode having the ability to operate in an operating system transparent or quasi-transparent manner, or in a privilege-level independent manner, for the purpose of executing low-level patches. For the purpose of the present application such a mode may be defined as a “sub-operating system mode”. One such mode is the system management mode (SMM). The existence of a sub-operating system mode may have additional system benefits, such as supporting transitions between power states.
To deal with software and hardware mismatches as outlined above, existing sub-operating system mode implementations may have no privilege restrictions or address mapping restrictions.
Sub-operating system modes may be invoked by a dedicated sub-operating system mode interrupt, sometimes generated by system firmware or system hardware, or occurring due to the execution of an instruction. This dedicated sub-operating system mode interrupt is usually designed to be non-maskable in order to respond to the exigencies that required the entry into the mode.
For example, in the case of SMM, the dedicated sub-operating system mode interrupt is called a system management interrupt (SMI). The processor may execute the mode's code in a separate address space. For example, when the mode is SMM, the separate address space allows access to system management random-access memory (SMRAM), which may be made inaccessible to the other operating modes. When entering the mode, the processor saves the context of the interrupted program or task within the separate address space. For example, in SMM the context is saved into SMRAM. During the execution within the mode, normal interrupts may be disabled. Finally, the mode may be exited by means of a resume instruction that may only be executed while executing within the mode.
The increasing number of financial and personal transactions being performed on local or remote computers has given impetus for the establishment of “trusted” or “secured” processing environments. The problem these environments try to solve is that of loss of privacy, or data being corrupted or abused. Users do not want their private data made public. They also do not want their data altered or used in inappropriate transactions. Examples of these include unintentional release of medical records or electronic theft of funds from an on-line bank or other depository. Similarly, content providers seek to protect digital content (for example, music, other audio, video, or other types of data in general) from being copied without authorization.
The existence of a sub-operating system mode, such as SMM, is a design challenge for designers of secure or trusted systems. Transitions to and from the sub-operating system mode can be difficult to handle gracefully, such that protected data remains secure and fault conditions are not generated. Indeed, a sub-operating system mode may have no privilege restrictions or address mapping restrictions and may therefore be incompatible with secure or trusted system architecture. This lack of privilege restrictions or address mapping restrictions often cannot be avoided by attempting to mask such a mode's dedicated interrupts, because these are usually designed to be non-maskable.